Add to_str for hashmap. #2899
Closed
Add to_str for hashmap. #2899
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This change shouldn't change the memory layout of hashmaps, because type synonyms get treated as if they've been expanded. If it does change the layout, that would be a pre-existing bug in the compiler. I agree unifying "%?" with I'll try to merge this. |
|
Oh, and happily, the refactor you did was independently made anyway by Patrick, to make the coherence checker happy (except the inner type is called |
|
Having trouble merging this. I think it might be a resolve bug. I'll look at it later on. |
ghost
assigned 
|
Integrated in 28519c8, thanks. |
|
Cool, np. |
Closed
bors
added a commit
that referenced
this pull request
Sep 4, 2018
Update RLS and Rustfmt RLS * Allow project model to download crates ([#1020](rust-lang/rls#1020)) * Support simple external builds ([#988](rust-lang/rls#988)) * Support using external Rustfmt ([#990](rust-lang/rls#990)) Rustfmt (0.99.4) * Format chains with comment ([#2899](https://github.com/rust-lang-nursery/rls/pull/2899)) * Do not show wildcard pattern in slice pattern ([#2912](https://github.com/rust-lang-nursery/rls/pull/2912)) * Impl only use ([#2951](https://github.com/rust-lang-nursery/rls/pull/2951)) * ... and [more](rust-lang/rustfmt@5c9a2b6...1c40881) Bumped in tandem to pull a single version of `rustc-ap-*` libs. r? @nrc
RalfJung
pushed a commit
to RalfJung/rust
that referenced
this pull request
May 23, 2023
Try to ensure measureme output is valid when the interpreter is interrupted Dropping our `measureme::Profiler` will have the profiler flush its output buffer and write out its string table. If the profiler's `Drop` impl does not run, the output file is not usable. This approach has zero runtime overhead.
celinval
pushed a commit
to celinval/rust-dev
that referenced
this pull request
Jun 4, 2024
Resolves: rust-lang#2714 Co-authored-by: Ted Kaminski <tedinski@amazon.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #2566.
I had to do a bit of refactoring to make this work, because there is already a to_str instance for \forall T.@t, and hashmap has type @{...}, so I couldn't make a to_str instance for hashmap. Instead, I factored out the raw record type as "inner", and put the to_str instance on that. This required moving the private helper methods onto inner as well, which I guess works fine because of magical auto-dereferencing when calling them.
The thing I most worry about is that I have somehow changed the memory layout / behavior of hashmaps by doing this, but I don't think so.
There seems to be an aesthetic choice here between calling to_str on the keys and values, versus printing them with "%?". I chose the former as more consistent, but the latter produces slightly more useful output (printing strings quoted, e.g.) It seems like there should be a more unified notion of how to print things, somehow. Shouldn't "%?" be using the to_str iface, where present? Is there some iface it does use?
[Oh, and the actual printing code, which was the least trouble in this whole exercise, is stolen from the json module, which is why it uses a writer. I could do something else if it would be more idiomatic.]